在 yaml file 中，除了前面說到的資料表、欄位說明之外，還有另一項重要的任務，就是測試（文件）。

老實說，我們的測試還不算太完整，雖然拿了很多後端的概念，有版控、有 CI/CD 等，但測試的部分，後端跟 Data 還是蠻不同的。

軟體要進行的測試是功能測試，部署完服務後，確認功能有正常運行即可。

在資料的部分也有類似的測試，像是測試 airflow 是否有被正常觸發、cloud run 正常運行等等，但 pipeline 不只是這樣。

pipeline 就算有正常運行，我們也無法直接確認資料是否正確。

在測試環境中，我們可以確保所有的資料表都有被建立起來，但只要我們並非拿全部的資料來測試，就沒辦法確認資料完全沒有遺漏，這是我們在測試環境中遇到最大的問題。

我們在每個資料表都隨機抽樣了一些，但當這些資料表 join 後就會有很多缺漏，沒辦法確認是因為只抽了部分資料的原因，還是轉換邏輯有問題。

這個痛點目前還沒有很有效的解決。

我們目前對於這部分有分幾個等級來做處理：

最高等級

針對一些對外公開的資料，我們進行最嚴謹的限制。

我們用了 dbt 中 constraints(文件) 的設置，這個設置與 test 的功能有些類似，不過 test 是事後檢查，在建立表格後，才檢查這張資料表是否通過測試；而 constraints 則是在 query 完畢後，先不建表，而是先確認資料符合限制，才進行建表，因此可以最嚴謹地確認這張表不會有不符合限制的資料被送進來。

models:
  - name: dim_customers
    config:
      contract:
        enforced: true
    columns:
      - name: id
        data_type: int
        constraints:
          - type: not_null
          - type: primary_key
          - type: check
            expression: "id > 0"
      - name: customer_name
        data_type: text
      - name: first_transaction_date
        data_type: date

第二級

針對我們過去有發生過問題的資料、或是也需要持續監控的資料，我們在不同的情境運用上有不同的檢查方式。

不過核心原則是類似的，就是將資料轉換的情況定期發送提醒。

像是每日的錯誤情況回報、每日輸入的資料量體等等，串接一些自動化工具把資料送到 slack 去做人工檢視之類的方法。

dbt 的 test 中也有一些方法，可以去針對欄位做一些運算，像是檢查每天的平均用量，是否有很大的波動，譬如 DAU, WAU 等等，若是偏離平均太多可能是轉換有誤，或也有可能是平台面臨重大危機 0.0

之前新開發了一些 openai 的 API 相關的服務，因為這個服務成本較高，我們就有去監控用量每小時的 rolling average，就有因此抓到一些有著奇怪 pattern 的使用者，才有機會再進一步去做一些限制跟管控，避免錢錢瞬間就被燒光。

普遍級

其他部分，我們大多僅使用 dbt 中預設的測試：unique, not_null, accepted_values and relationships。

在 marts 中做檢查，確保提供給業務單位的資料中，各個欄位與想像相符。

目前 dbt 提供的工具都還蠻足夠的，但我覺得這塊就是 DataOps 中最後 90 分要走到 100 分的環節吧，要付出蠻多心力來做維運才有辦法達成的項目，目前整個架構還有太多漏洞了，這題暫時先這樣，有需求的時候再來做提升。（可能要再給幾個 headcounts XD）